REMARKS 



Claims 1-6, 8-16, and 18-24 are pending in the application. 

Dependent claims 2-6, 8-10, 12-20, and 21-24 are currently amended. 

Applicants respectfully submit that entry of the currently amended claims above is proper 
because the currently amended claims will place the application in condition for allowance or in 
better form for appeal. Applicants further respectfully submit that no new matter is added to the 
currently amended claims, nor has the scope of the pending claims changed. Accordingly, no 
new issues are raised that necessitate a further search of the art. 

Claims 2-6, 8-10, 12-16, 18-20, and 22-24 stand rejected under 35 U.S.C. §112, second 
paragraph. 

Claims 1-6, 8-16, and 18-24 stand rejected under 35 U.S.C. § 103(a) as unpatentable over 
U.S. Patent Application Publication No. 2002/0178103) to Dan et al., hereinafter, Dan, in view of 
U.S. Patent Application Publication No. 2003/0167446) to Thomas, and in view of U.S. Patent 
Application Publication No. 2002/0042757 to Albazz et al., hereinafter, Albazz. 

Applicants respectfully traverse this rejection based on the following discussion. 

I. The 35 U.S.C. §112, Second Paragraph, Rejection 

Claims 2-6, 8-10, 12-16, 18-20, and 22-24 stand rejected under 35 U.S.C. §112, second 
paragraph, because the Office Action asserts the phrase "all the limitations of which are 
incorporated herein by reference" is indefinite. 

Applicants have deleted the objected to phrase in all of the currently amended dependent 
claims above. Withdrawal of the rejection of claims 2-6, 8-10, 12-16, 18-20, and 22-24 under 35 
U.S.C. §112, second paragraph, is respectfully solicited. 

II. The 35 U.S.C. §103(a) Rejection over Dan, in view of Thomas, and in view of Albazz 

A. The Dan Disclosure 

[0033] The TPA template or party profile may be included as part of the 
information advertised by the service provider in step 60 of FIG. 2. The profile 
serves as the starting point of a negotiation by providing an initial version of a 
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contract document. The profile may include information such as: products and 
services provided, specific business processes that the service provider can 
perform, security requirements, and technology information such as which 
message-exchange protocols are supported by the service provider. The service 
provider's profile may be embodied in a variety of different forms. Several 
examples of the service provider's profile are described herein, although 
alternative profile forms will be apparent to those of ordinary skill in the art. 

[0034] In one embodiment, the service provider's profile may describe the 
capabilities of one party. This profile may be expressed, for example, as an XML 
document whose contents may be incorporated into a contract. The information 
contained in the profile may include not only the capabilities of a party but also 
may contain requirements of the interacting party in the form of a contract 
template. The contract template is provided to express a contract either between a 
pair of roles or between an actual party (whose profile is represented by the 
template) and a role. One example of a contract template is an almost-complete 
electronic contract document with a few fields left blank: these fields are to be 
filled in by the negotiating party. An enhanced template additionally specifies, in 
an associated document, the acceptable choices for the negotiable fields. 

[0035] Fig. 4 is a schematic diagram that illustrates a party profile and a 
contract template. Party profile 1010 may contain, for example, party contact 
information 1011, a description of the service offered or needed 1012, one or more 
contract templates 1013, and allowable choices 1014. Allowable choices 1014 
may cover, for example, business and/or technical considerations such as a list of 
supported transport protocols, a list of supported shipping or transport services 
(such as overnight shipping, airmail delivery, etc.), delivery times, and/or the 
optional use of a preexisting meta contract. Profile 1010 may include a contract 
template 1020 containing one or more nonnegotiable fields 1021, 1022 and one or 
more negotiable fields 1023, 1024. As mentioned above, negotiable field 1023 or 
1024 may be treated as a blank that may be completed by the negotiating party or, 
alternatively, may specify capabilities or allowable choices that may be selected. 
The capabilities and/or allowable choices may be provided as searchable 
information by a public registry or repository. 

[0046] If either of the parties chooses to abort 340 the negotiation at any 
time during negotiations, the outcome 350 is the termination of the entire 
negotiation process. When all the sub components of a contract have been agreed 
to by both sides, the negotiation is committed in step 360, and the negotiation 
continues to step 380 where the negotiation is complete and step 380 leads to the 
service contract or TPA. 
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B. The Thomas Disclosure 

[0044] Once the user has finished entering modifications to the XML file 
and all of the modifications have been found to be either not significant or valid 
semantic changes, the temporary version of the XML file in the RAM 7 is written 
over the original file in the first storage region. Of course, the modified version 
of the XML file may be stored separately from the original version of the XML 
file instead of overwriting the original XML version. 

C. The Albazz Disclosure 

[0076] A product List Filter (PLF) is a representation of a seller's product 
list which replaces the completer list of all products available from a seller 
organization (as used herein the term "products" includes both products and 
services). This representation comprises product selection and/or exclusion 
criteria, based on a selection metaphor. The representation criteria are structured 
and stored in a way that ensures rebuilding the targeted product list from a master 
product catalog, or from multiple catalogs or other product information sources, 
any time the target product list is required. Depending upon the used PLF, a 
generated list could be static with the same products being produced at every run, 
or could be dynamic with new products being added or removed according to 
changes taking place at the seller organization. Fig. 5 illustrates an example of 
the creation and storage of a Product List Filter. 

D. Arguments 

Regarding the rejection of independent claims 1,11, and 21, the Final Action cites Dan 
for teaching "pre-building static structures of said XML transaction (Paragraphs 33-35)", (Final 
Action, page 3, section 8., C)). 

Dan discloses a contract template 1011, presumably analogous to a business transaction, 
containing one or more nonnegotiable fields 1021, 1022 and one or more negotiable fields 1023, 
1024. Dan also discloses that the profile serves as the starting point of a negotiation by 
providing an initial version of a contract document, i.e., the contract template, 1011. (Paragraph 
[0035]). 

The present invention defines a "static structure" as "a pre -built XML structure with pre- 
filled values based on the associated transaction type and TPP [Trading Partner Profile]", 
(Specification, paragraph [0024], lines 13-15). Therefore, the pre-built XML "static structures" 
of the present invention are static, i.e., unchanging, and pre-filled with values based on the 
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associated transaction type and trading partner profile. Hence, there are no negotiable fields in 
the static structures with pre-filled values of the present invention because the structures are 
static and pre-filled. 

In contrast, the contact template of Dan contains one or more negotiable fields 1023, 
1024 that will be filled with future negotiations. 

Therefore, Applicants respectfully submit that Dan does not disclose, teach or suggest the 
present invention's feature of "pre-building static structures of said XML transaction, wherein 
said static structures comprise a pre-built XML data structure with pre-filled values based on a 
transaction type of said XML transaction and a predetermined trading partner profile", as recited 
in independent claims 1, 11, and 21. 

Regarding the rejection of independent claims 1,11, and 21, the Final Action cites Thomas 
for teaching "wherein said final XML structure is validated by comparing said final XML structure 
against said copy of said original pre-defined data type definition format for said XML 
transaction" as "Once the user has finished entering modifications to the XML file and all of the 
modifications have been found to be either not significant or valid semantic changes, the 
temporary version of the XML file in the RAM 7 is written over the original XML file in the first 
storage region 4" (Paragraph 44 [of Thomas]). (Final Action, page 5, line 27 to page 6, line 3). 

In the present invention, a business partner agrees to send a business transaction in a 
mutually agreed upon XML format (proprietary or standards based), call a Data Type Definition 
(DTD) format. Next, a Trading Partner Profile (TPP) is created in a database that holds 
information about the partner, the communication protocol used, the enabled transaction, format of 
transaction, and XML format version. Then, a copy of the DTD is created. Thereafter, static 
elements of the XML are filled with pre-determined values based on the TPP and are stored using 
an editor. The static sections are linked to the TPP and transaction , and are stored in the database. 
At execution time , based on the TPP and transaction combination, the corresponding static sections 
are taken and the application specific dynamic sections are built to construct the final XML . 
Execution time is defined as the transaction runtime (that is, sending the transaction to the trading 
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partner). The constructed XML is then run against (compared against) the DTD to validate the 
structure . (Specification, Paragraph [0028]). (emphases added). 

Thomas discloses that the temporary copy of the contents of the XML file is displayed 29 
by means of the output interface 10 so that a user is able to input modifications to the XML file via 
the input interface 9. Each of the changes entered by the user is compared 30 to the temporary 
copy of the XML file and checked 31 to establish whether the modification is significant, i.e., a 
semantic change. . . . Where the modification is identified as a semantic change, the processor 
checks 34 whether a valid difference representation of the change can be generated using the delta 
DTD [i.e., Document Type Definition]. (Paragraph [0043], lines 2-8 and 13-16). 

Thomas further discloses that the DTD of the delta file and the DTD of the original markup 
language file are substantially identical in that the nested structure of the contents of the delta file 
and the original file will be substantially the same. However, certain slight modifications are 
necessary to enable the delta file to represent the changes to the markup language file. All of the 
element type declarations are either copied across to the delta DTD or amended and the element 
type declarations are processed to the lowest level of each content particle. (Paragraph [0048], 
lines 7-15). 

Thomas discloses a method of recording and validating changes to a markup language, 
wherein semantic changes to the original XML file necessarily require slight modifications to 
enable a delta file to represent changes to the original markup language file. These slight 
modifications may entail amending element type declarations and processing these element type 
declarations to the lowest level of each content particle. However, the DTD of the present 
invention is originally fixed and its DTD copied, and does not require such slight modifications or 
amending of element type declarations as does Thomas because the final XML structure of the 
present invention comprises pre-filled static structures, to which no modifications or amendments 
of the DTD are made, and dynamic structures that comprise empty tags, to which no modifications 
or amendments of the DTD are made, so that the final or constructed XML structure may be 
compared to or validated against the original pre-defined data type definition. 

Therefore, Applicants respectfully submit that Thomas does not disclose, teach or suggest 
the present invention's feature of "wherein said final XML structure is validated by comparing 
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said final XML structure against said copy of said original pre-defined data type definition 
format for said XML transaction", as recited in independent claims 1, 11, and 21. 

Furthermore, for at least the reasons outlined immediately above, Applicants respectfully 
submit that Thomas does not cure the deficiencies of Dan, because Thomas does not disclose, 
teach or suggest the present invention's feature of "pre-building static structures of said XML 
transaction, wherein said static structures comprise a pre-built XML data structure with pre-filled 
values based on a transaction type of said XML transaction and a predetermined trading partner 
profile". Instead, Thomas merely discloses a method of recording and validating changes to a 
markup language, wherein semantic changes to the original XML file necessarily require slight 
modifications to enable a delta file to represent changes to the original markup language file. 

Regarding the rejection of independent claims 1,11, and 21, the Final Action cites 
Albazz for teaching "building a list of a sequence of said static and dynamic structures". (Final 
Action, page 7, lines 6 and 7). 

Albazz merely discloses generating a list that could be static with the same products 
being produced at every run, or could be dynamic with new products being added or removed 
according to changes taking place at the seller organization. (Paragraph [0076]). 

In contrast, the present invention describes the feature of "building a list of a sequence of 
said static and dynamic structures", wherein both static and dynamic structures are previously 
defined, i.e., "pre-building static structures of said XML transaction, wherein said static structures 
comprise a pre-built XML data structure with pre-filled values based on a transaction type of said 
XML transaction and a predetermined trading partner profile; classifying dynamic structures of 
said XML transaction with empty tags and single occurrence classifiers for repeating dynamic 
structures". 

The static and dynamic product lists of Albazz do not disclose, teach or suggest the present 
invention's features of "wherein said static structures comprise a pre-built XML data structure with 
pre-filled values based on a transaction type of said XML transaction and a predetermined trading 
partner profile" or "dynamic structures of said XML transaction with empty tags and single 
occurrence classifiers for repeating dynamic structures". The static and dynamic product lists of 
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Albazz are not explicitly defined as XML data structures corresponding to a transaction. A list is 
not a transaction. 

Therefore, Applicants respectfully submit that Albazz does not disclose, teach or suggest 
the present invention's feature of "pre-building static structures of said XML transaction, wherein 
said static structures comprise a pre-built XML data structure with pre-filled values based on a 
transaction type of said XML transaction and a predetermined trading partner profile; classifying 
dynamic structures of said XML transaction with empty tags and single occurrence classifiers for 
repeating dynamic structures; building a list of a sequence of said static and dynamic structures", 
as recited in independent claims 1,11, and 21. 

Furthermore, for at least the reasons outlined immediately above with respect to Albazz 
and above with respect to Dan and Thomas, Applicants respectfully submit that Albazz does not 
cure the deficiencies of Dan and Thomas, because Albazz also does not disclose, teach or 
suggest the present invention's feature of "pre-building static structures of said XML transaction, 
wherein said static structures comprise a pre-built XML data structure with pre-filled values 
based on a transaction type of said XML transaction and a predetermined trading partner 
profile". Instead, merely discloses generating a list that could be static with the same products 
being produced at every run, or could be dynamic with new products being added or removed 
according to changes taking place at the seller organization. 

For at least the reasons outlined above, Applicants respectfully submit that Dan, Thomas, 
and Albazz, either individually or in combination, do not disclose, teach or suggest the present 
invention's features of "pre-building static structures of said XML transaction, wherein said static 
structures comprise a pre-built XML data structure with pre-filled values based on a transaction 
type of said XML transaction and a predetermined trading partner profile; classifying dynamic 
structures of said XML transaction with empty tags and single occurrence classifiers for repeating 
dynamic structures; building a list of a sequence of said static and dynamic structures", as recited 
in independent claims 1,11, and 21. Accordingly, Dan, Thomas, and Albazz, either individually 
or in combination, fail to render obvious the subject matter of independent claims 1,11, and 21, 
and currently amended dependent claims 2-6, 8-10, 12-20, and 21-24 under 35 U.S.C. § 103(a). 
Withdrawal of the rejection of claims 1-6, 8-16, and 18-24 under 35 U.S.C. § 103(a) as 
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unpatentable over Dan, Thomas, and Albazz is respectfully solicited. 



III. Formal Matters and Conclusion 

Claims 1-6, 8-16, and 18-24 are pending in the present application. 

Applicants respectfully submit that claims 2-6, 8-10, 12-16, 18-20, and 22-24, as amended 
above, fulfill the statutory requirements of 35 U.S.C. §1 12, second paragraph. 

In view of the foregoing, Applicants submit that claims 1-6, 8-16, and 18-24, all of the 
claims presently pending in the application, are patentably distinct from the prior art of record and 
are in condition for allowance. The Examiner is respectfully requested to pass the above 
application to issue at the earliest possible time. 

Should the Examiner find the application to be other than in condition for allowance, the 
Examiner is requested to contact the undersigned at the local telephone number listed below to 
discuss any other changes deemed necessary. Please charge any deficiencies and credit any 
overpayments to Attorney's Deposit Account Number 09-0456. 



Respectfully submitted, 



Dated: February 28, 2008 /Peter A. Balnave/ 

Peter A. Balnave, Ph.D. 
Registration No. 46,199 

Gibb & Rahman, LLC 
2568-A Riva Road, Suite 304 
Annapolis, MD 21401 
Voice: (410) 573-5255 
Fax: (301) 261-8825 
Balnave@Gibb-Rahman.com 
Customer Number: 29154 
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